abi: minor 7 — whole-row layout probe, and the classid table made global - #30

… global

Three corrections and one addition, all from the same observation: a classid is
a GLOBAL address that captures LAYOUT.

CLASSIDS ARE NOT PER-SoA. The classid -> grouping table was on RowStore, one
64 KiB copy per dataset. The same classid means the same class in every SoA, so
the resolution is dataset-independent -- provably here, since FixtureClassView
is a unit struct with no per-store state. Hoisted to a process-global LazyLock
in class_view_provider, where it belongs: it is a property of the ClassView, not
of any store. Wrong in shape rather than in output -- the answers were right,
but the placement implied two datasets could disagree, which the address space
does not permit.

THE TABLE CAPTURES LAYOUT ONLY. Meaning, RBAC, ontology category and render
template are separate resolutions off the same address; none belong in it and
none can be inferred from it. Stated in the doc so the table does not accrete.

lgj_row_layout_probe: for EVERY facet, the set of groupings its selected rows
carry, in ONE crossing. Asking per facet would be 32 crossings and is how a
consumer drifts into the per-element loop §6 forbids.

Alignment falls out as arithmetic rather than a scan: per facet, OR-accumulate a
3-bit set (plus one bit for an unanswerable classid), then

    aligned  <=>  popcount(byte) == 1 && no unanswerable bit

One `or` per (row, facet), no comparison, no early exit, cost independent of the
data. An OR-accumulated SET is exact where cheaper accumulators are not: a sum
of wire values cannot tell {0,2} from {1,1}, and an XOR cannot tell {1,1} from
{}. The set forgets multiplicity, which is exactly what the question does not
need. 0 means the EMPTY set and is deliberately distinguishable from
disagreement.

It paid immediately. A test asserting that a maskOfFacetClass(facet 3, …)
selection is fully aligned FAILED -- and the expectation was wrong, not the
code: that mask constrains facet 3 only, so the other 31 facets carry whatever
classids the generator gave them. Measured 1 of 32 facets aligned. That is the
confusion a whole-row probe exists to remove.

R10 (valhalla-lab) bolts the same three schemas into Valhalla and Panama and
proves all three descriptions agree: raw storage bytes, a Panama MemoryLayout,
and a Valhalla value class decode every register identically, each layout
describes exactly 12 bytes, and the schemas genuinely read differently so the
agreement is not trivial. The schema bolts on at the GROUP, not the register:
12 = 6x2 = 4x3 = 3x4 means the largest group is 4 B (half the budget) while the
register is 12 and the facet 16, neither of which Java can flatten or needs to.

Gates: 132 Rust, 288 Java, clippy -D warnings clean, fmt clean, abi 0.7.